<p>Executing code dynamically is security-sensitive. It has led in the past to the following vulnerabilities:</p>
<ul>
  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2017-9807">CVE-2017-9807</a> </li>
  <li> <a href="https://www.cve.org/CVERecord?id=CVE-2017-9802">CVE-2017-9802</a> </li>
</ul>
<p>Some APIs enable the execution of dynamic code by providing it as strings at runtime. These APIs might be useful in some very specific
meta-programming use-cases. However most of the time their use is frowned upon as they also increase the risk of <a
href="https://owasp.org/www-community/attacks/Code_Injection">Injected Code</a>. Such attacks can either run on the server or in the client (example:
XSS attack) and have a huge impact on an application’s security.</p>
<p>This rule raises issues on calls to <code>eval</code> and <code>Function</code> constructor. This rule does not detect code injections. It only
highlights the use of APIs which should be used sparingly and very carefully. The goal is to guide security code reviews.</p>
<p>The rule also flags string literals starting with <code>javascript:</code> as the code passed in <code>javascript:</code> URLs is evaluated the
same way as calls to <code>eval</code> or <code>Function</code> constructor.</p>
<h2>Ask Yourself Whether</h2>
<ul>
  <li> the executed code may come from an untrusted source and hasn’t been sanitized. </li>
  <li> you really need to run code dynamically. </li>
</ul>
<p>There is a risk if you answered yes to any of those questions.</p>
<h2>Recommended Secure Coding Practices</h2>
<p>Regarding the execution of unknown code, the best solution is to not run code provided by an untrusted source. If you really need to do it, run the
code in a <a href="https://en.wikipedia.org/wiki/Sandbox_(computer_security)">sandboxed</a> environment. Use jails, firewalls and whatever means your
operating system and programming language provide (example: <a
href="https://wiki.sei.cmu.edu/confluence/display/java/SEC54-J.+Create+a+secure+sandbox+using+a+security+manager">Security Managers</a> in java, <a
href="https://www.w3schools.com/tags/att_iframe_sandbox.asp">iframes</a> and <a href="https://en.wikipedia.org/wiki/Same-origin_policy">same-origin
policy</a> for javascript in a web browser).</p>
<p>Do not try to create a blacklist of dangerous code. It is impossible to cover all attacks that way.</p>
<p>Avoid using dynamic code APIs whenever possible. Hard-coded code is always safer.</p>
<h2>Sensitive Code Example</h2>
<pre>
let value = eval('obj.' + propName); // Sensitive
let func = Function('obj' + propName); // Sensitive
location.href = 'javascript:void(0)'; // Sensitive
</pre>
<h2>Exceptions</h2>
<p>This rule will not raise an issue when the argument of the <code>eval</code> or <code>Function</code> is a literal string as it is reasonably
safe.</p>
<h2>See</h2>
<ul>
  <li> OWASP - <a href="https://owasp.org/Top10/A03_2021-Injection/">Top 10 2021 Category A3 - Injection</a> </li>
  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">Top 10 2017 Category A1 - Injection</a> </li>
  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/95">CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval
  Injection')</a> </li>
</ul>
